預寫日誌 Write Ahead Log (Wal)

前情提要

前面介紹了postgres透過wal機制與shared_buffers來達到原子性(Atomicity)與持久性(Durability)，
並且透過master複製 WAL 來達到與Slave 中做同步。
那麼今天就來介紹mysql會是如何達到相同目的的，其實mysql也是採用WAL技術，不過使用的日誌與機制稍微不同。
今天將會介紹mysql的

1. 重做日誌（redo log）
2. 滾回日誌（undo log）
3. binary log
   來完成相同的目的。

redo/undo log

redo/undo概念有點類似於在撰寫migration

重做日誌 redo log

顧名思義就是當如果有需要做動作時，就可以讀取redo log來進行該動作
和postgres的wal基本上就是同樣的概念，只不過pg因MVCC的關係，
如有殘留數據因有clog也不用擔心會顯示，所以不需要undo log，
而mysql因底層為sxlock的設計，因此需要使用undo來記錄上一步驟該如何恢復。

我們知道tx開始到commit中間有許許多多的sql command，
而在這之中會先修改進memory之中，而非真實的先寫入硬碟中的table，
而中間的時間差就是先將操作寫入redo log後再修改memory中的狀態(類似於postgres的shared_buffers)，
當在收到commit後，redo log就開始一步一步的寫進硬碟之中。
就算中途發生問題，我們也還有redo log來接續著接入。
當順利寫完memory中的操作後，就可以插入一個checkpoint，
來告知這裡之前的資料都已經順利寫入硬碟之中了，下次redo也會從這裡開始撰寫。

持久性(Durability): 事務完成之後，對系統的修改是永久性的。
重點在於 commit 時就算還沒寫完硬碟中途 crash 也救的回來。

因此可以用來達到ACID的Ｄ持久性(Durability)。

滾回日誌 undo log

顧名思義就是當想要返回上一步時，就可以讀取該log，來返回上一步
這裡的下一步上一步指的是sql語句
如上一步是 create
下一步就是 delete
意即就是redo log的反操作。
當tx開始到rollback之前，也有著許許多多的sql，
在memory上的狀態也是在rollback之前的樣子，
必須使用undo log來做反操作，才能順利的將資料回復原狀。

Atomicity 原子性: 每次的操作都是全部成功，或是全部失敗滾回，沒有其他選項。
重點在於不論 tx 中間做了哪些事情，只要需要 rollback，都可以順利的回復到原本的樣子。

因此可以用來滾回到特定的版本，用來保護原子性(Atomicity)。

binary log

在postgres之中，只需要透過傳遞wal日誌就可以達到master與slave同步的效果。
那個mysql有redo log，那麼不就也可以透過redo log來達成呢？
完全不對，我們知道mysql有分redo/undo log，就是tx中間做的任何事情都會紀錄，就連rollback也是。
其實我們可以在commit後，在另外寫到一個binary log中，這樣就可以只記錄下確定要存的所有資料了。
舉的例子: 當我們要插入10萬筆紀錄，redo log就會在過程中依序紀錄這10萬筆，
當寫到最後時rollback，那麼前面這10萬筆都白寫了，不過還是會被記錄在redo/undo log中。
那麼binary log就如同沒什麼事情發生一樣。

Replication

既然已經知道mysql已經有binary log來記錄下所有該存入硬碟中的記錄.
相同的,mysql也是有與postgres相同的存檔式(archive)與流式(streaming)複製,
傳送到 Slave 中

結語

這裡我們使用講解了Mysql的WAL機制，並且使用redo/undo log來完成 A(atomic)D(durability)。
當如果想要做讀寫分離，也可以使用binary log來實作流式(streaming)與存檔式(archive)的複製。

參考資料

1. 【MySQL】169 Redo日志和Undo日志的理解、为什么需要Redo日志